home *** CD-ROM | disk | FTP | other *** search
/ Columbia Kermit / kermit.zip / newsgroups / misc.20020314-20021006 / 000041_ishikawa@yk.rim.or.jp_Wed Apr 24 14:13:11 EDT 2002.msg < prev    next >
Text File  |  2020-01-01  |  3KB  |  74 lines
  1. Article: 13332 of comp.protocols.kermit.misc
  2. Path: newsmaster.cc.columbia.edu!panix!howland.erols.net!news.maxwell.syr.edu!newsfeed.media.kyoto-u.ac.jp!newsfeed.rim.or.jp!news.rim.or.jp!not-for-mail
  3. From: Ishikawa <ishikawa@yk.rim.or.jp>
  4. Newsgroups: comp.protocols.kermit.misc
  5. Subject: Re: a bug on GNU/linux: speed reset to unintended value occasionally.
  6. Date: Thu, 25 Apr 2002 02:22:31 +0900
  7. Organization: Ye 'Ol Disorganized NNTPCache groupie
  8. Lines: 50
  9. Message-ID: <3CC6E9D7.F4F2C624@yk.rim.or.jp>
  10. References: <3CAFF81C.8039CBF8@yk.rim.or.jp> <a8q34m$l3l$1@watsol.cc.columbia.edu> <3CB1D4F3.10D79B1F@yk.rim.or.jp> <a8svsu$3vl$1@watsol.cc.columbia.edu> <3CBAB0BC.1D3ABF7B@yk.rim.or.jp>
  11. NNTP-Posting-Host: pl1447.nas911.n-yokohama.nttpc.ne.jp
  12. Mime-Version: 1.0
  13. Content-Type: text/plain; charset=iso-2022-jp
  14. Content-Transfer-Encoding: 7bit
  15. X-Trace: news.rim.or.jp 1019668953 68363 210.139.44.167 (24 Apr 2002 17:22:33 GMT)
  16. X-Complaints-To: root@rim.or.jp
  17. NNTP-Posting-Date: Wed, 24 Apr 2002 17:22:33 +0000 (UTC)
  18. X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.18 i686)
  19. X-Accept-Language: ja, en
  20. Cache-Post-Path: duron!unknown@localhost
  21. X-Cache: nntpcache 2.3.3 (see http://www.nntpcache.org/)
  22. Xref: newsmaster.cc.columbia.edu comp.protocols.kermit.misc:13332
  23.  
  24. >Has anyone noticed this sub-optimal speed
  25. >using Kermit on two closely
  26. >placed PCs at 38400 bps?
  27.  
  28. It turned out that the apparent slowdown 
  29. was an artifact of
  30. sending binary file, namely wermit.
  31. I got a much better throughput when
  32. I tried to send largish ascii file such as
  33. /etc/termcap.
  34.  
  35. This was again the two ports connected
  36. directly by cross/null cable.
  37.  
  38. It puzzled me for a while, but
  39. finally I figured it was a slowdown
  40. caused by the prefixing or quoting of
  41. binary characters:
  42.  
  43.  If I disable the prefixing via 
  44.  
  45.     set control-character unprefixed all
  46.  
  47. then I got an improved throughput.
  48. (With prefixing I got sub-3KB/sec throughput.
  49. Without prefixing I got over-3KB/sec throughput.)
  50.  
  51. One would not usually remove prefixing
  52. unless we know the transmission occurs via
  53. clean direct connection.
  54. Kermit has a reason to be conservative. It is one of
  55. the best file transfer program 
  56. under a noisy/lossy/disruptive
  57. environment.
  58.  
  59. The reason I got interested in the throughput was
  60. that I was curious to learn if
  61. the throughput improves when I use full 8 bits
  62. connection instead of 7 bits connection.
  63. Obviously at this speed (38400), we are already close
  64. to the limit of serial port, and 
  65. whether we use 7 bits or 8 bits isn't that important.
  66. Other overhead such as prefixing masks 
  67. the improvement, if any, of using full 8 bit character
  68. transmission path.
  69.  
  70. Thank you again for the great software package.
  71.  
  72.  
  73. Happy Hacking!
  74.